home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 137_01 / dec83col.ddj < prev    next >
Text File  |  1980-01-01  |  15KB  |  304 lines
  1. .pl 60
  2. .po 0
  3. ..
  4. .. "The C/Unix Programmer's Notebook"
  5. ..
  6. .. DDJ Column #2        as of 19-Sep-83
  7. .. (C) 1983 Anthony Skjellum.   All rights reserved.
  8. .. For publication in DDJ
  9. ..
  10. ..
  11. .. file (DDJCOL2.WS)        created:  19-Sep-83
  12. ..                updated:  24-Sep-83
  13. ..                updated:  
  14. ..
  15. ..                completed: 25-Sep-83
  16. ..
  17. .he "C/Unix Programmer's Notebook" by Anthony Skjellum. (C) 1983.  For December, 1983, DDJ.   
  18.  
  19.  
  20.                                A Correction
  21.  
  22.     In  the last column,  several references to the book The C Program-
  23. ming  Language  and  its  authors  were  made.   Through  my  error,  Brian 
  24. Kernighan's  name was misspelled consistently throughout the  column.   I'm 
  25. sure that many readers noticed this immediately.   Unfortunately,  I didn't 
  26. until I saw the column in DDJ.
  27.  
  28.                                Introduction
  29.  
  30.     In  this second Programmer's Notebook,  I'll discuss how  Unix-type 
  31. environments  can  lead to non-interactive,  and user-unfriendly  software.  
  32. This  is  based  on experiences I've had with several  Unix  and  Unix-like 
  33. systems running both standard and Berkeley Unix.  
  34.  
  35. ..       Last  time,  I discussed incompatible linkage formats  and  runtime 
  36. .. libraries  of  C compilers in both the eight and sixteen-bit  world.   This 
  37. .. time,  the  discussion will concentrate on problems and  difficulties  I've 
  38. .. encountered  through  in with linkers and C libraries in my work under  MS-
  39. .. DOS.
  40.  
  41.     Skimming through the ads in the October DDJ,  I noticed that nearly 
  42. twenty-five  percent of the ads concerned or mentioned C or Unix.   Most of 
  43. them concerned C.   This indicates strongly that C and to a lesser  extent, 
  44. Unix,  are  popular items with DDJ readers.   I also hope that reader input 
  45. will be significant as it has been with other DDJ columns.
  46.  
  47.     I  also saw an extremely interesting advertisement in  the  October 
  48. DDJ.  This was a Computer Innovations ad concerning the soon-to-be-released 
  49. version  of  their C compiler.   As an option,  this compiler will  produce 
  50. programs/data  exceeding the previous limit of 64K segments imposed by  all 
  51. 8086 compilers (C or otherwise) that I've seen.  Look for a review in  this 
  52. column early next year.  
  53.  
  54.                      Unix and non-interactive Software
  55.  
  56.     The  Unix  operating  system was designed to reduce  repetition  of 
  57. programming effort by permitting modular programs to be combined via  pipes 
  58. and  tees.   Since  input and output are redirectable  under  Unix,  simple 
  59. programs could use console input and output for one application and be used 
  60. as  part of a pipeline for another.   Thus,  unmodified programs  could  be 
  61. reharnessed  for  new applications to an extent not possible with  previous 
  62. operating systems.  
  63.  
  64.     Pipes  and input-output redirection are two of the best  and  well-
  65. known  features  of the Unix system.   Microcomputer users have  been  very 
  66. interested  in  adding these capabilities to their own  operating  environ-
  67. ments.   In the eight-bit world, this has been done chiefly through special 
  68. subroutine  libraries such as "The Unica," or in C runtime  packages.   For 
  69. MS-DOS 2.0 users, the features are built into the operating system.  
  70.  
  71.     Despite  the  undisputed usefulness of pipelines  and  input-output 
  72. redirection,  their  presence in Unix has lead to a serious drawback in the 
  73. system's environment.  This drawback is the proclivity to avoid interactive 
  74. programs   and  to  produce  user-unfriendly  software.   Furthermore,  the 
  75. standard  Unix  console  interface is weaker  than  under  other  operating 
  76. systems.   In  the remainder of this column I will discuss these weaknesses 
  77. as I perceive them.  
  78.  
  79.                          Non-interactive Software
  80.  
  81.     Because of the availability of pipes and input-output  redirection, 
  82. many  Unix programs are designed to act as filters.   Filters are  programs 
  83. which  require  a single sequential input data stream and produce a  single 
  84. output data stream.   Such programs are suitable as pipe-fittings.  Because 
  85. of  the  way  they  handle data,  they don't normally  expect  to  be  used 
  86. interactively.   In  most  cases  this doesn't pose a  problem  for  users.  
  87. However,  because such programs do not expect to deal directly with humans, 
  88. but only with input and output streams,  they can often be very  unfriendly 
  89. in the area of error handling.  
  90.  
  91. ..
  92.     The  problem in the Unix system is that the same  terse  philosophy 
  93. applied  to  filters also pervades most of the  software  available.   This 
  94. includes programs which are normally executed sequentially by the user from 
  95. the  console.     The  problems  come in several areas and  some  of  these 
  96. problem  areas  are  listed  in Table I.   The  following  paragraphs  will 
  97. elaborate each of the points listed in that table.
  98.  
  99. ---------------------------------TABLE I.---------------------------------
  100. -----------------------(Unix software Problem Areas)----------------------
  101.  
  102.         1.  terse (hard-to-remember) program names.
  103.         2.  lack of program sign-on and sign-off messages.
  104.         3.  lack of interactive mode to alleviate the need
  105.             to re-execute a program several times to complete
  106.             a set of operations.
  107.         4.  inconsistent use of switch (dash options) for
  108.             controlling the specifics of program execution.
  109.         5.  lack of descriptive error messages.
  110.         6.  cryptic, incomplete, and erroneous documentation
  111.         7.  software bugs: un-documented and documented.
  112.         8.  cryptic (or missing) internal help features.
  113.         9.  poor console interface provided by Unix.
  114.         10. lack of system for finding program names by the 
  115.             function required.
  116.         
  117. ------------------------------END OF TABLE I.------------------------------
  118.  
  119. .pa
  120.                                 Terse Names
  121.  
  122.     Unix  program names are usually two or three letters long and  tend 
  123. to  be  cryptic.   While  this saves  typing  for  experienced  users,  its 
  124. frustrating  for  new and occasional system users.   Also,  since the  Unix 
  125. system  lacks  an  on-line indexing system for  finding  program  names  by 
  126. function,  it's  not  easy to find the right program based on  the  desired 
  127. function alone.  
  128.  
  129.                           Sign-ons and Sign-offs
  130.  
  131.     Sign-on and Sign-off messages are a common courtesy in the computer 
  132. world.   Virtually  all  standard  Unix  programs  lack  these  two  simple 
  133. features.   While  this  is understandable for filters,  it  is  completely 
  134. unnecessary for other programs.   For example, if two versions of a program 
  135. exist on a system,  the only easy way to distinguish them is by their sign-
  136. on messages.  
  137.  
  138.     Besides sign-ons/offs, its also nice for a program to give progress 
  139. reports  during  execution.   This  lets  the  user  know  how  things  are 
  140. proceeding.   Standard  Unix  software  doesn't  normally  include  such  a 
  141. feature.
  142.  
  143.                           Internal Help Features
  144.  
  145.     Many  programs include a feature summary option to help  occasional 
  146. and new users remind themselves of program operation.   Many Unix  programs 
  147. also have this capability, but they are often extremely cryptic and include 
  148. few English words to supplement the sample command line which they display.  
  149. Figure I.  displays a sample session in which a ficticious program  (called 
  150. fct)  is executed from the shell with no arguments.   The program  responds 
  151. with  a cryptic help summary typical of actual Unix  commands.   In  Figure  
  152. II.  the  same fct program session is presented,  but this time the program 
  153. has  been  designed to provide a user-friendly help feature  (and  also  to 
  154. sign-on and off).  
  155.  
  156. ---------------------------------FIGURE I.--------------------------------
  157. ---------------------------(Cryptic fct Session)--------------------------
  158.  
  159.     $ fct <RETURN>        (activate the program with no arguments)
  160.     usage: fct -abcv file1..fileN    (help message)
  161.     $            (shell prompt)
  162.  
  163. -------------------------------END FIGURE I.------------------------------
  164. .pa
  165. --------------------------------FIGURE II.------------